This invention relates to embedded devices connected to networks that have clients such as web browsers running on one or more host computers.
Embedded devices (i.e., devices which combine electronic hardware and software and possibly mechanical parts or other components, and which are specifically designed to perform a dedicated function or task; e.g., vending machines, appliances, motor controllers, printers) are often designed to work in conjunction with host computers to provide features such as enhanced user interfaces (using the host computer display), remote access (via a network to which both the host computer and embedded device are connected), and firmware upgrades (loading a new firmware version into the embedded device from the host computer). By leveraging the capabilities and resources of the host computer, the embedded device is able to overcome internal resource constraints that are inherent due to cost and/or size limitations of the embedded device. These constraints often manifest themselves as limitations in the amount of memory (e.g., bytes of random access memory) and/or processing power (e.g., processor speed, data bus size, instruction set, and onboard peripherals) of the embedded device.
Looking a bit closer at the issue of memory constraints in embedded devices, random access memory (RAM) is particularly of concern. Single-chip microcontrollers, which are often used in embedded devices, typically have limited RAM and rely on other types of memory (e.g., flash memory) to store programs and other constant data. For example, a currently popular microprocessor platform for embedded devices is the ARM7. Two of the leading ARM7 suppliers, Atmel Corporation and NXP Semiconductors, both offer ARM7 devices with network connectivity (in the form of Ethernet media access controllers). The Atmel AT91SAM7X family provides four times the amount of flash memory than RAM memory (e.g., the top-of-the-line AT91 SAM7XC512 includes 512 KB flash and 128 KB RAM). The disparity is even more pronounced in the NXP LPC2368, which includes 512 KB flash and only 58 KB RAM. Since RAM is frequently a very limited resource in embedded devices, it is especially desirable to reduce RAM usage in embedded devices.
Two common techniques for leveraging the capabilities and resources of host computers are: i) installing custom software on each host computer that will interact with the embedded device, or ii) incorporating an HTTP server in the embedded device that generates content suitable for an HTTP client (i.e., web browser) on the host computer. Each method has its strengths and weaknesses.
A strength of custom software is that it enables resource-constrained embedded devices to thoroughly leverage the capabilities and resources of the host computer, due to the ability of custom software to access and control many aspects of the host computer.
A weakness of custom software is that it typically needs to be installed and maintained on each host computer that will access the embedded device. In practice, this is often cumbersome, time consuming, and expensive, especially in business environments where typically only IT departments are allowed to install software. Each new version of the custom software requires updates or new installations, and compatibility issues frequently arise due to interactions between the custom software and different versions of computer operating systems, different combinations of other custom software applications installed on the host computer, and/or mismatches between versions of the custom software and versions of the embedded devices.
A strength of incorporating an HTTP server in the embedded device is that it provides for a “zero footprint” client, meaning that a standard HTTP client (e.g., web browser) of a host computer can be used to access the embedded device from any host computer that has the client installed. Since the great majority of personal computers have web browsers pre-installed, this is a major improvement over custom software.
A weakness of incorporating an HTTP server in the embedded device is that resource constraints of the embedded device, such as the earlier mentioned memory and processing power limitations, can severely impact the user experience in terms of i) quality, such as the usability of a user interface or the sophistication of a report that can be generated, ii) quantity, such as the size of a report that can be generated or the size of a file that can be read, iii) responsiveness, such as how quickly the embedded device can generate requested content, and/or iv) scalability, such as the number of clients that can be simultaneously serviced.
Although there are technologies available that provide for varying degrees of client-side processing (e.g., Flash® Player by Adobe Systems Incorporated, OpenLaszlo™ by Laszlo Systems Incorporated, and the Java™ Runtime Environment by Sun Microsystems Incorporated), these technologies are typically not specifically designed or optimized for working with embedded devices and thus typically do not take into account the special requirements and limitations, of resource-constrained embedded devices. As a result, existing technologies generally suffer from one or more of the following problems:                1. They are not designed to explicitly minimize memory usage (e.g., RAM and/or flash) and/or processing bandwidth in the server (i.e., embedded device) and may therefore not run effectively on resource-constrained embedded devices.        2. They do not provide tools for reading, writing, and/or manipulating arbitrarily large files while taking into account the limited resources of embedded devices.        3. They are not designed to dynamically update content or do so inefficiently.        4. They do not cleanly separate static content (which can be cached by the client) from dynamic content.        5. They are not designed for general client-side processing (e.g., they focus on presentation layer processing).        6. They require proprietary developmental tools (e.g., available only from a particular company, and/or only for a particular platform) thus limiting development options.        7. They require server-side components, programming languages and/or scripting languages that are not generally available for or are poorly suited for use on embedded devices.        8. They require additional software to be installed on the client (e.g., browser plug-ins).        9. They do not support a wide range of clients (e.g., a wide range of browser platforms).        10. They support only a single type of content (e.g., Flash® SWF files) or a limited range of content.        11. They do not provide tools for accessing resources from external domains.        
Note that the preceding list of problems is intended to be illustrative in nature, and is not intended to serve as an exhaustive list of every aspect of existing technologies that may render them inappropriate for embedded devices.
Therefore, what is needed is an effective method for resource-constrained embedded devices to interact with host computers, which can ideally provide for one or more of the following:                1. A zero footprint client that does not require any custom software to be installed at the host computer.        2. A significant reduction in the amount of memory and processing power that is required by the embedded device to produce sophisticated, complex, and high quality content, including dynamic content.        3. An ability to generate content that is much larger (potentially orders of magnitude larger) than can fit within the available memory of the embedded device.        4. An ability to store arbitrarily large files to the host computer and/or to file systems accessible to the host computer.        5. An ability to read, process, and extract information from arbitrarily large files from the host computer and/or from file systems accessible to the host computer.        6. A solution that maximizes the amount of content that can be cached by the client.        7. A generalized and “generic” solution that is not significantly limited in the type of content that can be generated or the type of processing that can be performed at the client.        8. A solution that is not dependent on specific third-party products, browser plug-ins, development tools, etc.        9. A solution that is effective across a broad range of clients and embedded devices.        10. A solution that can be easily and flexibly adapted to the requirements of the specific application and to the resources of the specific embedded device.        11. An ability for the client to efficiently aggregate data from multiple embedded devices while placing minimal memory and processing requirements on the embedded devices.        12. A generally improved overall user experience when interacting with the embedded device through the host computer.        